Android IPC

携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第4天，点击查看活动详情

前面文章我们重点分析了Linux的进程划分，以及为了减少一次拷贝的内存映射技术，本篇文章我们就来介绍Android中使用最多也最具有代表性的IPC方式：AIDL。

本篇文章主要侧重AIDL的使用细节，然后重点分析AIDL生成的文件，通过手写AIDL生成文件来大致理解Binder机制，话不多说，直接开整。

我们先来看看AIDL的使用。

AIDL的原理是通过Binder来实现，而且是C/S架构，所以AIDL分为服务端和客户端2个方面来使用：

从这个简单描述我们知道，作为服务端必须建立在Service上，这也非常好理解，Service作为四大组件之一，由Android系统统一管理，同时自己就可以被其他进程所启动；

从客户端实现我们可知这里的关键就是Binder了，本篇文章后面我们在使用AIDL时会简单说明一些Binder相关类的作用。

为了更好地说明AIDL使用的细节，这里我使用俩个APP交互的方式，而不是一个APP开启多进程。

AIDL接口的的创建非常重要，首先是需要定义在不同进程之间传递的自定义类型，比如我这里定义为Book：

这是一个Book.java类，必须实现Parcelable接口，然后就是存放该类的目录，这里推荐把涉及到AIDL通信的自定义类都放到一个相同的目录中，这是因为俩个进行跨进程通信的APP会对自定义的类型对象进行序列化和反序列化，而这种序列化方式会记录类的信息，即使俩个APP中都定义了Book类，而且成员变量都一样，但是因为包名不一样，同样是无法反序列化的。

定义完自定义类型后，凡是在AIDL文件中用到的自定义Parcelable类型，都必须新建一个和它同名的AIDL文件，并且在其中声明它为Parcelable类型，而AIDL文件的目录，可以使用AS直接创建出来，这里在AIDL目录下创建一个Book.aidl:

再然后我们就可以定义AIDL接口了，该接口就是定义IPC通信的内容，注意这个接口和Java接口有一点不一样，它是只支持方法的，不支持声明静态常量，在本例中创建管理Book的接口IBookManager.aidl：

这里需要注意俩点：

创建完AIDL文件以及AIDL用到的自定义Parcelable类型，这时就需要把这些文件从服务端APP拷贝一份到客户端APP中，注意类的包名千万不要改变，当一端的类结构发生改变，在另一端必须替换为一样的。

在定义完AIDL接口后，需要Build一下项目，这时在app/build/generated/aidl_source_out_dir/debug目录下会生成一个和AIDL接口同名的java文件，即IBookManager.java，关于这个文件我们后面会仔细分析。

这里先来看一下服务端如何实现，前面说了需要通过Service，直接定义一个服务BookManagerService:

这个类涉及的知识点比较多，我们来挨个分析：

类似的集和还有ConcurrentHashMap线程安全的集和。

这里mBinder是IBookManager.Stud类的实例，这个类是AIDL文件生成的文件，该类定义如下：

可以发现它继承至Binder，这个Binder就是IBinder的实现类，同时实现了IBookManager接口，根据IBinder接口的特性，这里我们就可以认为这个mBinder就具有了跨进程的能力。

前面既然说了对象实现了IBinder就有了跨进程的能力，那可以想象在客户端应该就是拿到刚刚在服务端定义的Binder对象，然后对这个Binder进行操作，所以客户端代码如下：

这里的核心代码就是IBinder对象的asInterface了，这里可以看成就获取到了服务端的Binder了(真实原理我们后面再说)。

我们看一下打印：

这里会发现list的类型是ArrayList，为什么说这个呢 原因是刚开始我们说AIDL支持List，但是只支持ArrayList，但是我们在服务端代码中却用了CopyOnWriteArrayList，这个类定义：

会发现它虽然是名字和ArrayList相关，但是它却不是继承至ArrayList，这就说明了数据在传输过程中，Binder对数据类型做了处理。

这里还有注意一点，就是客户端调用完getBookList方法后，会挂起当前线程，直到等待结果返回，是一个同步方法，所以当在服务端该方法执行时间过长，在主线程调用该方法可能会导致ANR。

这里我们可以做个小小总结：

在前面我们已经说了AIDL的简单使用了，现在我们加个功能，就是在AIDL中使用回调。

这个功能在开发车机、电视等系统中经常用，比如导航APP在运行时，一般需要在Launcher显示出导航的简短信息，这个导航实时信息就是导航APP通过回调给的。

在本章例子中，我们添加一个回调监听，希望服务端每隔一段时间能主动回调当前Book的信息。首先我们定义接口，这个接口也必须定义为aidl类型：

这里为什么要定义为AIDL接口，因为接口中的方法是需要跨进程调用的，方法回调的数据是需要序列化和反序列化的，所以一般的Java接口肯定满足不了；

定义完新接口后，需要在原来接口中添加注册和反注册的方法：

修改完AIDL接口，需要Build一下项目，然后在服务端进行简单修改：

上面代码非常简单，和保存Book一样也新建一个listener列表，然后在onCreate方法中，每隔5s回调一次Book信息，同时对Binder实现类添加了注册和反注册的功能。

写完服务端代码，必须把修改涉及的文件拷贝到客户端，这一步千万不能出错，在客户端中一样先Build，然后在服务连接成功后，创建监听的实例，给注册到服务端：

这里要注意的上面已经注释了，就是在跨进程中，我们定义监听的接口必须是aidl类型的，而非普通的Java类型，所以客户端在注册时必须是传递生成类Stub的对象，至于原因后面会细说；这里创建了IOnBookListener.Stub的实例，但是通过跨进程后，客户端实例和服务端实例将不是同一个，上面代码的运行如下:

可以发现可以正常实现功能，每5S回调一次服务的Book列表信息。

既然我们可以注册listener，当然也需要测试一下反注册listener，但是在反注册listener中，我们会发现如下打印：

服务端居然提醒找不到该listener，并且客户端还是一直在回调，这不是大坑吗 这就是AIDL使用回调时需要注意的点。

我们在客户端新建listener对象，通过Binder传递到服务端后，会生成一个全新的对象，这是因为IPC的本质是序列化和反序列化，对象是需要序列化后才可以传输，所以这个listener在客户端和服务端俩个进程就不是一个对象。

既然不是同一个对象，那回调功能咋是正常的呢，这个后面分析AIDL生成文件时细说，这里先解决如何正常反注册。

解决的办法非常简单，使用RemoteCallbackList来代替前面的CopyOnWriteArrayList集和，从名字就可以看出这个是专门用来存放远程回调的，我们可以简单看一下该类的定义：

可以发现它是一个泛型类，而泛型类型是IInterface，这个接口很重要，定义如下：

RemoteCallbackList原理非常简单，在它的内部有一个Map结构专门用来保存所有AIDL回调，这个Map的key是IBinder类型，value是Callback类型：

而当我们注册一个回调时，其中的key和value是如下方法获取：

到这里我们就明白了，虽然说跨进程传输中，在客户端新建的对象和服务端不是同一个，但是这俩个对象对应的Binder对象是同一个，所以当注册和反注册时可以针对对应的Binder来进行增删。

同时RemoteCallbackList还有一个很有用的功能，就是当客户端进程终止后，它能自动移除客户端注册的listener，而且RemoteCallbackList内部自动实现了线程同步功能，所以我们使用它来注册和反注册时，不需要做额外的线程同步工作。

为了程序的健壮性，当服务端进程意外停止时，我们需要重新连接服务。在这里重新连接服务，有俩种方法：

代码如下：

定义完deathRecipient后，在bindService成功的回调中给binder添加该死亡监听即可：

到这里，AIDL的使用我们基本就说完了。其实AIDL文件是一套java代码生成规则，可以看成是给编译器来使用的一套规则，通过AIDL文件，编译器生成符合跨进程通信的java代码。 这样的好处就是不用让开发者编写复杂的跨进程代码。

会使用AIDL还是不够的，必须要能看得懂AIDL文件所生成的java文件，因为在很多源码中，都是直接使用java代码来编码的。

前面说了当IPC时我们需要定义.aidl接口，这个接口就是IPC的内容，当定义了一个IBookManager.aidl接口，这个接口肯定不能直接起作用，它会生成一个IBookManager.java，代码如下：

上面生成的代码还是蛮多的，看起来有点乱的原因是定义了太多内部类，首先就是IBookManager.java这个类，它继承了IInterface接口，同时它自己也是一个接口，所有可以在Binder中传输的接口都必须继承至IInterface接口。

同时在IBookManager.java中定义了俩个方法，这俩个方法就是我们在aidl中定义的方法，是IPC希望实现的功能接口。同时定义了俩个静态整形的id分别用来标识这俩个方法，这个俩个id用于标识在transact过程中客户端所请求的到底是哪个方法。

然后是IBookManager.java中的第一个内部类：Default，该类是默认实现，可以无需关注。

IBookManager.java中第二个内部类：Stub，其中Stub的意思是"存根"，表示一些接口的实现类。该类是核心，它首先是继承至Binder，同时实现了IBookManager接口，下面详细列举一下该类中的实现细节：

该方法的参数非常重要，服务端通过code可以确定客户端所请求的目标方法是什么，然后从data中取出目标方法所需要的参数，然后执行目标方法，当目标方法执行完毕后，会向reply中写入返回值。这里注意，如果此方法返回false，那么客户端的请求会失败，因此我们可以利用这个特性来做权限验证，毕竟我们不希望随便一个进程都能远程调用服务。

上面便是AIDL的生成文件的简单分析。

在前面我们也说了.aidl文件只是生成Java代码的规则，而且这里我们也分析了AIDL生成的文件，所以我们就可以不用AIDL来手动创建Binder对象，这样一样可以实现IPC通信。

这里定义了ICustomBookManager的Java接口，并且定义了俩个方法以及方法的唯一表示符号。

可以发现上面代码和生成的代码几乎一样，只不过可读性多了很多，里面关键的地方可以归纳如下几点：

不知不觉本篇文章的子树已经非常多了，内容较多，下面做个总结：

笔者水平有限，如有问题，欢迎大家评论指正。